As shown in FIG. 1, an electronic device 1 including a smart card 2 is set up to operate according to an event-driven example. One of the fundamental modules of the smart card is referred to as a framework 4, such as a terminal interface protocol manager for example. The framework belongs to a given processing environment, such as an operating system waiting for a set of external actions.
For a better understanding of the present invention, hereinafter an “event” will be referred to as any significant action performed by an external entity 7 that involves the processing environment in the electronic device 1. The external entity 7 is also referred to as the “world” in the schematic of FIGS. 1 and 2, and may be a user or a network to which a terminal is linked. In other words, the world 7 can be a user or the communication network that interacts with the smart-card 2 or the terminal itself.
Once an event has occurred the framework 4 is triggered, invoking a predetermined sub-program that is an autonomous programming application provided with an independent life-cycle. This programming application is loaded on the processing environment and has somehow negotiated with the framework the decision to be associated with a specific event.
This kind of negotiation may be called “event registration”. Thus, the application has substantially two opportunities: a first opportunity for managing the occurred event, or a second opportunity for reacting according to the quality of the event. Registration of an event and triggering of the framework 4 is achieved due to a well-defined interface between the framework and the programming application.
When an event takes place, however, before triggering a target programming application, the framework 4 usually performs standard operations related to its own responsibilities regarding that event. Only after completion of these standard operations, the framework 4 calls registered programming applications and finally performs further operations to complete event-related resource management.
The framework 4 is one of the elements of the processing environment, such as the smart-card 2. Many applications can be functionally separated in a central module 5 and one or more complementary modules 6. Suppose that a programming application that is called to react after an event might be functionally separated in several modules 5, 6. The separation is such that the modules can be described as follows:
1) A central module 5 that is structured to comply to the following duties: a) performing main operations directly linked to an event, such as administrative operations; b) implementing well-known and/or stable behavior fulfilling requirements of most products and without needing frequent upgrades after issue; and c) optionally, its implementation is correlated to the system architecture of the processing environment, and more particularly, if development of the module is difficult, this development can be done only by an expert development team skilled or trained on that system architecture, and/or requiring, partially or totally, architecture-dependant programming language.
2) One or more complementary modules 6, which are structured to comply to one or more of the following duties: a) performing complementary operations to be started after completion of the central module processing, e.g., user or network notification, resource de-allocation etc.; b) optionally, the complementary operations must be started after the completion of central module 5 processing and after the framework 4 has completed the event management; c) accessing to the same input data of the central module, as well as to its output data, d) implementing specific product or specific customer requirements, such as user interactions or network acknowledging with specific data; e) being subject to a rapid and/or custom development, for instance using high level or portable language, with system architecture hiding; f) they can be developed by third-parties not skilled on the system architecture or not qualified to access to the system programming resources; g) the requirements may be unknown at application release; h) the requirements may be eligible to change during product life cycle and could be upgraded on the field; and i) a small memory usage is expected.
The easiest way to implement this separation is by allowing the central module 5 to invoke the complementary module 6 as an external program. An example of this possible structure is shown in FIG. 3. A practical case concerning a Smart-Card Application Architecture, such as a 3GPP 43.019 SAT Application (SIM Application Toolkit) will now be considered. This provides a mechanism for triggering and an event registration of the previously disclosed kind.
A hypothetical applet that respects the previous duties (1) and (2) can comprise two modules. Both a central module 5 and a complementary module 6 can be developed as distinct Javacard applets. The complementary applet, however, is provided with a shareable interface exported to the central module 5, which has the function of calling the complementary module 6.
The central module 5 is most eligible to be developed also in architecture-dependant or Javacard with partial native implementation. The complementary module 6 can be loaded, installed and updated also on the field, via a Remote Applet Management.
A further example will now be considered. For instance, in a computer based system the complementary module 6 can be written as a stand-alone executable, called within the central module 5 with proper operating system APIs. In this case, step 3 of FIG. 2 is a command that executes an external program, usually provided by an operating system.
Both the above approaches present some drawbacks. A first disadvantage is due to the fact that the definition of a non-standard interface is required to achieve inter-module communication and inter-module run-time linking management.
In other words, both modules shall comply to a precise communication protocol, more or less complex, to exchange input and output data. Moreover, the central module shall dynamically manage the potential presence of the complementary module.
These approaches still require the framework completing its duties before starting the complementary operations. In other words, good performances must rely on the ability of the framework 4 to complete event management before the triggering of a complementary module 6. For instance, the complementary module 6 should run in a clear and unambiguous condition when the definitive result of event processing is known.
As an example, with reference to an application toolkit environment, the SIM is allowed to return data (9Fxx) before the complementary module is triggered. On the contrary, with reference to a GUI based operating system, this would be desirable to permit the redrawing, or generally speaking, the unlocking of a GUI resource such as a window or a button before execution of the complementary module.